[レポート]Content Hub「ケーキの層のごとく、レジリエンスを習得する」に参加してきました。#ARC327
こんにちは。中村です。
本記事は Content Hub「Mastering resilience at every layer of the cake」 の参加レポートになります。
突然時間が空いたため、直前で本セッションに参加してきました。
15分前にwalk-upの列に並びました。私より前に30人程、並んでいたため、参加できるかドキドキの状態で並び、参加に至りました。
概要
Most workloads on AWS resemble a finely crafted cake, with delight at every layer. In this session, master resilience at each layer of deliciousness: from platform to infrastructure and applications, using services like AWS Resilience Hub, AWS Fault Injection Service (FIS), Amazon Route53 ARC, Amazon Elastic Disaster Recovery (DRS), AWS Backup, and more. Leave with a mental model for how resilience works throughout these layers, with ready-to-use reference architectures and prescriptive guidance. This session keeps things fun and lively along the way, with lots of demos!
[機械翻訳]
AWSの多くのワークロードは、層ごとに楽しみがある精巧なケーキのようなものです。このセッションでは、AWS Resilience Hub、AWS Fault Injection Service (FIS)、Amazon Route53 ARC、Amazon Elastic Disaster Recovery (DRS)、AWS Backupなどのサービスを使用して、プラットフォーム、インフラストラクチャ、アプリケーションといった各層での回復力(レジリエンス)を習得します。これらの層全体でレジリエンスがどのように機能するかのメンタルモデルと、すぐに使える参照アーキテクチャ、および実践的なガイダンスを持ち帰ることができます。このセッションは、多くのデモを交えながら、楽しく活気のある方法で進めていきます!
スピーカー
- Jenny Zhou
- Christopher A Vokolos
- Shllomi Ezra
レベル
- 300
内容
まとめ
- レイヤーに応じた対策を実施
- 復旧処理は、コントロールプレーンに依存するのではなく、データプレーンからを検討する
- AWS Resilience Hubを利用してテストしてみる
内容ピックアップ
まずは、レジリエンスとは何か?を考えてみます。
障害から復活すること。その回復力のこと。と今回は考えてみます。
サービス提供には様々なリソースが関係しています。
ユーザが提供するアプリだけでなく、それを動かしているインフラなど。
ケーキの様に層を成しているレイヤー毎に、検討しましょう。
ここで、AWSへ命令を行うAPIの挙動についてみてみます。
グローバルサービスに注目してみます。
認証を行う際は、何を利用するのが良いのか?
コントロールプレーンに依存するのではなく、データプレーンに依存する様に構成してみましょう。
確かに、コントロールプレーンに該当するAPI操作は、その実装自体の複雑さがあるため、データプレーンの方を利用した方が良さそうです。
次に、レジリエンスについて2種類に分類してみます。
- 基礎的なレジリエンス
- マルチAZ構成にするなど
- 継続的なレジリエンス
- 適宜、モニタリングするなど
私的には、ベストプラクティスに従って、マルチAZ構成など検討できている方は多いイメージがあります。
しかしそんな方でも、モニタリングはできていますか?
この部分は再度、一歩立ち止まって振り返ってみることも重要です。
このセッションでは、続いてデモを見せていただきました。
レジリエンスを意識して構築したら、テストをしてみたくありませんか?
そう問いかけられている気がしました。
ここで紹介されたサービずが「AWS Resilience Hub」です。
下記は、事前に作成したcloud watchダッシュボードでモニタリングしながら、テスト実施による変化を見ている画像です。
AZ Availability: Power Interruptionを利用してAZ障害のテストを実施しました。
ダッシュボードを継続的に確認していくと、モニタリングの値から、AZの切り替えが行われていることがわかりました。
ただ作成するだけでなく、障害復旧もテストすることで確かな回復力を確認できるのは良いですね。
感想
今回は、飛び入り参加でセッションに参加しました。
私自身、AWS Resilience Hubを使ったことがなかったので、マルチAZ構成でテストを行う際にぜひ使ってみたいなと思いました!